hit and miss need to be understood relative to the kind of policy to make sense. hit a deny == denied. hit an allow == allowed. Would users be better served with "allows" and "denies" which inform them of a concrete result taken in association with this policy?

I worry an allow policy with deny: 123 looks alarming. Its not really a deny, its more like it failed to allow

So if a policy doesn't match, miss/deny will be incremented, even if another policy later on allow or denies it?

I also wonder if the order of operations might cause the stats to be confusing. For example, if there are multiple deny policies, but only one of them matches, then the order in which the deny policies are evaluated will affect the stats (assuming there is some short circuiting), which seems weird.

Maybe a better say of saying this is, why do we need miss when we can just do total_requests - hit

there is no total request counter for a policy

I mean total request counter across for ztunnel in general

That doesn't exist is the first issue. We could add it but it doesn't help the use case.
Miss means "policy applies to the request but does not match"

Ok then only my second comment then: This doesn't seem to take into account short circuiting. Just because a policy could apply, short circuiting might mean that a counter doesn't get incremented, which might be the intended behavior

ack, will need to fix that